title: Security, Privacy, and Compliance
aliases: [Security Audit, FERPA COPPA]
tags: [3netra/wiki, security, privacy, compliance]
product: 3netra Meta Android App
source_repository: 3Netra-ai/3n_meta_android
source_ref: origin/prod
source_revision: b48aada8fd5427b5db0c02945569963c4ae543c8
last_verified: 2026-08-06
up: "[[Home]]"

Security, Privacy, and Compliance

Data classification

Trust boundaries

flowchart LR
    Student[Student/user] -->|consent and actions| Device[Android trust boundary]
    Device -->|public client credentials| Supabase[Supabase trust boundary]
    Device -->|media and prompts| Edge[Supabase Edge Function trust boundary]
    Backend --> Model[AI vendor trust boundary]
    Device --> Sarvam[Sarvam trust boundary]
    Staff[Faculty/Disability Specialist] -->|enrollment authority| Device

Verified controls

• Supabase manages authentication instead of a custom password store.
• Teacher/Admin PIN values are BCrypt-hashed before local storage.
• An AES-backed encrypted local face-storage utility includes a 90-day retention concept, but no active call site uses it.
• The Android app invokes a Supabase Edge Function for AI. Its returned model text is discarded in the current client; this is not evidence of a secure or working AI boundary.
• Runtime permission rationale screens explain camera, microphone, location, Bluetooth, and notifications.

Critical gaps

1. Biometric path mismatch: active face enrollment stores CSV embeddings in Supabase; the encrypted local store is unused.
2. No repository proof of RLS: schemas, migrations, policies, grants, and RLS tests were not found in the reviewed app. Client checks are not authorization.
3. Consent not operational: a default-false consent field and fabricated age do not constitute student/guardian verification.
4. Misleading privacy copy risk: UI claims about on-device recognition or FERPA compliance exceed verified controls.
5. Face model fail-open: model-load failure can yield random embeddings rather than disabling recognition.
6. Sensitive logging: device/session identifiers, similarity values, and embedding samples may enter Android logs.
7. Client configuration: API values compiled into the app are extractable. Only public/publishable values belong there.
8. Signing assets: a release keystore is tracked in the secondary Android project; release signing ownership and secret handling need remediation.
9. Emergency reliability: incomplete GPS/wiring makes the SOS capability unsafe to represent as operational.
10. Credential exposure and server boundary: secret-like configuration is compiled into the app or committed as fallback source configuration; the AWS prototype also contains a provider-authorization implementation. Do not reproduce values in docs; rotate/revoke exposed material and move all provider secrets to managed server/Edge-function secret stores.
11. Undemonstrated retention: active face records are cloud rows; no repository code invokes the local 90-day cleanup, and the SAM bucket has no lifecycle configuration.

Supabase security requirements

• Enable RLS on every table exposed through the Data API.
• Use ownership/relationship predicates; TO authenticated alone is not object-level authorization.
• Give update policies both USING and WITH CHECK, and ensure required select policies exist.
• Keep authorization roles in app metadata or relational tables, never user-editable metadata.
• Never ship a service_role or secret key in the Android app.
• Confirm whether tables are exposed to Data API roles; exposure grants and RLS solve different problems.
• Test student, instructor, and unauthorized cross-tenant access as separate identities.

Minimum biometric lifecycle

stateDiagram-v2
    [*] --> Notice
    Notice --> StudentConsent: student approves
    StudentConsent --> Enroll: named subject and purpose recorded
    Enroll --> Active: encrypted embedding stored
    Active --> Accessed: recognition request authorized
    Accessed --> Active: audited
    Active --> Deleted: withdrawal, retention expiry, account deletion
    StudentConsent --> Denied: declined
    Denied --> [*]
    Deleted --> [*]

Compliance interpretation

FERPA and India's DPDPA are product/legal obligations, not SDK features. Current documents express alignment goals, but the repository does not prove compliance. Before production use with students, obtain legal review and produce:

• authoritative age/audience policy;
• student consent and revocation workflow;
• biometric consent and retention policy;
• role and institution-tenant authorization matrix;
• RLS schema and automated policy tests;
• vendor/subprocessor and cross-border data inventory;
• deletion/export workflow and audit evidence;
• incident response and child-safety review.